The heart of a modern computer system is the software program which controls and coordinates the operation of the hardware components. The series of commands or steps which comprise the program are generally stored in a text file called a source code file. The program statements in the source code file are generally human-readable and can be composed and edited by the program developer. As will be explained in more detail below, the human-readable source code is converted, or compiled, by another program called a compiler into binary object code which can actually be executed by the hardware.
When computer systems were first developed, both the hardware and the software programs were considerably simpler than they are today. The hardware consisted of a single processor and early software programs were relatively small and compact and generally consisted of a single text file which held the source code.
As both hardware and software became more sophisticated and software development progressed, programs grew in size and complexity. Therefore, it became necessary to break the program into smaller, more easily understood pieces. Breaking the program into pieces also had the advantage that, during program development, each piece of source code could be separately compiled into object code, a process that was much faster than compiling the entire program. Also, due to the complexity and time required to develop reliable software code, techniques were developed that allowed code pieces which were already developed to be reused in different parts of a single program and also between two separate programs.
For example, structured programming techniques were developed where most of the source code was written as separate subroutines and the main program simply calls the subroutines. In many cases it was convenient to store collections of the subroutines in separate files.
With the advent of object-oriented programming, the potential of reusing portions of prewritten code is greatly increased, but the complexity of the programs has increased even further. More particularly, as will hereinafter be described in more detail below, object-oriented programs consist of a collection of inter-related objects. In many modern programming languages each of these objects is typically defined by a header file which contains definitions of the data structures and the subroutines, or methods, which comprise the object. The object further has a source code file which contains the code which implements the methods. In a modern object-oriented program, the number of objects easily climbs into the hundreds and, in some cases, into the thousands. As with structured programs, collections of objects are generally placed in separate files so that a complex program may include hundreds of files.
Since the objects are interrelated, it is common for program files to reference other program files. This interrelation necessitates some type of file management to keep track of the files during compilation. For example, a typical program development sequence is shown in greatly simplified form in FIG. 1.
More particularly, the sequence starts in step 100 and proceeds to step 102 where overall design criteria are established for the software program. Then, in step 104, a program developer composes source code in order to control the computer to meet the design criteria established in step 102. As previously mentioned, the source code may comprise many different files which correspond to classes for creating, menus, icons, bitmaps, text strings, screen layouts and other components of the system.
Next, in step 106, the source code is compiled by a compiler program into object modules. Each separate source file may be compiled separately into a corresponding object module which contains binary code. The separate object modules are linked together in step 108 by means of a linker program to generate an executable program (which can actually be run on a computer). Next, in step 110, the executable program is run and evaluated against the design criteria established in step 102. If, based on the results of the evaluation in step 110, the program is found to meet design criteria in step 112 then the program development is finished (indicated by step 116). However, if the program is found not to meet design criteria, the source code is edited in step 114 and the compilation and linking steps, 106 and 108, are then repeated until the program eventually meets design criteria.
Generally, the editing of the source code in step 114 involves editing of some, but not all of the source code files. However, since some of the files may reference other files, certain source code files may have to be recompiled even if they have not themselves been modified. For example, if a subobject is modified the object file which contains a reference to the subobject may also have to be recompiled in step 106. Thus, it is necessary to keep track of references between files so that different changes or revisions to a file will reflect changes to other related files.
One conventional way to maintain references between source code files is a "project" file. The project file is a simplified database which maintains a list of source code files along with the references between the files and the current state of each file (whether the file has been modified or not). Generally, the file state is maintained by a date and time stamp which is applied to each source code file when the file is modified. When a project file is used, the compilation step takes the form of a project "build" during which all source code files in the project database which, need recompiling are sequentially compiled. The project file also contains a date and time stamp for the last build time. The next time the executable program is built, the program development management software compares the time stamp of each source code file to the time stamp saved in the project file during the last program build. Those source codes files which have a time stamp later than the last build date are recompiled before linking.
The project file approach works well for small and medium size projects where only a few people are working on the project at the same time, however, in large projects, the project file approach becomes a bottleneck. In such large projects, there are often program development teams which share objects and other program components within a project and between projects. Accordingly, it is necessary in large projects to have some type of source code control program which can coordinate use of the these objects among projects to insure that the correct version is used during compilation.
Several commercial source code control systems are presently available including RCS, SCCS, and MPW Projector, however, these systems manage current versions of the source code for individual files and are not capable of managing any other additional information that can be used to control the code, for example, extra configuration information. Further these systems cannot provide history information concerning versions of the relationships between files which are useful for comparison and merging purposes.
Accordingly, it is an object of the present invention to provide a program development management system which supports the reliable sharing and reuse of objects and other program components by a program development team.
It is another object of the present invention to provide a program development management system which maintains configuration and revision information and which can store different code versions developed over time.
It is still a further object of the present invention to provide a program development management system which utilizes a distributed database operating over a network.